EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/misc/noahsarc.lha/Noahs.Arc/Part4

Text File | 1995-10-05 | 36KB | 775 lines

  Now as the months roll by and you get to downloading various things from
the BBS's and picking up the odd Fish disk, you're going to end up with
programs all over the place, so we need to do two things in preparation.

  The first is getting our archives together.  These disks will be our
library.  When we download a program off a BBS it comes compressed, to both
keep the file size down as well as keeping the whole package in one tidy
bundle.

  When you get a compressed download, you decompress it with whatever
archiver it was originally compressed with.  Right now, LHA is the current
archiver of choice, although I, personally, have all my board files in the
new LZX format, which is the first of the "smart" archivers and hopefully
will replace LHA.  It's MUCH better.

  After that you look at the freshly decompressed files, read the docs and
try out the program.  Then, if it looks like a program you want, or MIGHT
want down the road, you copy the original version to your file library.

  You'll have drawers on these archive disks and you'll file the programs
correctly, as well as have a master text file of what's where, its size,
brief description and where you got it from.  Give yourself LOTS of
elbow room on these archives; they fill up quickly and it's a bitch to
expand, say, six disks to ten just because of all the copying and trying to
keep things in their proper drawers, etc.


  My archive disks are as follows; you can use them to help plan your own:

  Ads - BBS ads for hardware/software mail-order companies, etc
  BBS - captured buffers of file listings
  Clock - clock/timer stuff

  Anims - six disks of animations

  Audio - audio progs

  Audio Samples - sound and music files

  CLI - CLI-related progs

  Docs - two drawers, regular docs and game docs & hints

  Diskcopiers - misc BBS copiers
  Fonts - downloaded fonts, font progs

  GamesA-C - downloaded games

  GamesD-F -

  GamesG-M -

  GamesN-S -

  GamesT-Z -

  GraphToolsA-L - all graphics-related programs

  GraphToolsM-R -

  GraphToolsS-Z -

  HacksA-M - misc hacks

  HacksN-Z -

  Icons - nothing but
  IconTools - editors and converters

  Keyboard - progs directly related to the keyboard
  Mouse - mouse progs, including menu-makers

  Misc - whatever doesn't fit somewhere else

  Pics#1 - pics I'd really mind losing

  Pics#2 -

  Pics#3 -

  Pointer - misc pointers, pointer progs
  Printer - a few special drivers, controllers
  Say - a couple of oddball things (could go in Audio)

  Screens - things concerning screens
  TextTools - progs dealing with textfiles

  ToolsA-E - except diskcopiers and graphtools

  ToolsF-P -

  ToolsQ-Z -

  Windows - window-related progs


  Yes, it seems silly to have an entire category just for the pointer, but
I've got EIGHT files in there, so what'ya want?

  One point to note is that the number of disks for each category doesn't
reflect your interest in that particular area of the computer.  It's just
that some programs are naturally huge, like the anims, so even if you're
just mildly interested in them, you'll still end up with a few disk's worth.

  If you don't have a modem yet but have picked up a few Fred Fish disks
down at the store, the same holds true:  Get them stored.  Usually you only
want a program or two, so my advice is to store what you want and put the
Fish disks in a box in the closet to pull out six months from now to see
if you've changed your mind about any of the other programs.  DON'T use
the Fish disks, cleaned and formatted or not, for your archives, as they're
poor quality.  And if you're using the Sonys, you mustn't stoop so low as to
use a generic disk.

  And BACKUP your archives!  Spend half a Sunday every four months or so
with your archive disk on one side of the DU and the backup disk on the other
side, copying over the latest additions.  Yes, it's boring.  Yes, it takes
forever.  Yes, you'll think you're the smartest person since God created
kittens when you accidentally wipe out some archive disk three months from
now and have a copy safely secreted away.

                                       *

  The other thing we have to do in preparation for the new programs invading
our tidy Amigaworld is to make some specialized CustomBenches.  If you like
icons, you'll end up with a bunch of different icon utilities, so make a
copy of BareBench, rename it IconBench, and go through it as we did before,
deleting any file that doesn't relate to icons.  I'm just talking about Tools
and things, of course.  We obviously leave the l, libs, and devs directories
mostly alone.  But just about everything else you can find besides the CLI
goes.  Hey, this is the IconBench, buddy.  Move what's left over to the main
Workbench window, then "Delete Utilities all".  We note that even though we
moved everything out of Utilities, the directory's still not empty (there's
still the .info file) so "Delete Utilities" without the "all" won't work..
directory not empty!  Then "Delete Utilities.info" to blast the icon.

  DiskDoctor might also be in there (without an icon), but it goes too for
the IconBench.

  Remember, I'm capitalizing words simply for clarity; the CLI doesn't care.
Good advice right now would be get into the habit of always capitalizing cer-
tain words: directory names, program names, c commands, whatever strikes your
fancy.  There're no strict rules on the subject, as pointed out quite clearly
by the stock startup-sequence.  In the tutorial I'll just capitalize every-
thing in sight.

                                       *

  All right:  As you can see, you'll end up with a bunch of different
Benches.  You'll have a GraphBench where you'll have different graphics
tools for showing pics, running slideshows, animations, etc.  You'll have a
FirstAidBench filled with DiskDoctor-type programs, undeleters, file-
zappers, whatever, in case of need.  You'll have ExperiBench for screwing up,
maybe a MusicBench for music programs, NoteBench (with ProWrite or something
on it), DirtyBench, hey, who knows?

  There is, however, another way to do all this, but it has too many
drawbacks..disks are cheap, remember?  I'll explain it to you anyways just
so you know.  Assuming you have a blank, formatted disk in df1, you can, of
course, store tools (in drawers, if you wish) on that disk and simply run
them by opening df1's window and double-clicking on the icon.  Also, because
the disk in df1 isn't a boot disk and doesn't need all the accompanying files
like Workbench does, it can hold just tons of tools, eliminating the need
for almost all of the CustomBenches.  For all of that, you REALLY want df1
free to transfer things to and from, and if you start running projects and
things from df1 you'll end up being plagued by "Please insert disk so-and-
so.." requesters.  And that's only the start of some of the hassles that
might crop up, another being that paths are much more critical with
something running from an external device, be it df1 or Ram.  I tried it
for a while and gave up.  It's more fun and certainly easier to deal
with just having custom Benches for different major operations and leave
df1 free for file shuffling, holding big programs, collections of pictures,
animations, etc.

  Not to mislead you, you'll still use good ol' Workbench as your standard
boot-up disk.  The CustomBenches are just that, for custom work.  And you
can always run a tool or whatever from df1 in a given situation.

                                       *

  So what's next?  Why, time to write a scriptfile, you bet!  Type in the
CLI "Ed s/g" and there's our buddy Ed with a Creating New File for us.  The
file is in the s directory and is called "g".  Pretty snazzy name, huh?  On
the first line type "Ed df0:s/startup-sequence".  That's it!  Hit Esc, x,
Return.  In the CLI type "Dir s" and see if little g is there.  In the CLI
"Type s/g" and see your fine creation right there in blue and white.  Now
type "Execute s/g" in the CLI and lo and behold, you've executed a scriptfile
that told the computer to edit the startup-sequence.  Hit Esc, q, Return, to
quit the Ed without saving anything.

  Think that was tricky?  Watch this:  Type "Copy c/Execute c/f" in the CLI.
You've just duplicated the Execute command, renaming it "f".  Now in the CLI
type "f s/g" and you've got Ed again.  Still not slick enough?  Hang on.

  The command Path draws a path into a directory so we can find and use a
TOOL easily.  We'll use the ol' Clock as our example.

> Move the Clock into the Utilities drawer with the mouse.
> Type "Clock" in a CLI and the little beggar should pop right up there.
> Close the Clock, then type "Path reset" in the CLI.

  We have just wiped out (for this CLI) the command "Path Ram: System
Utilities" we ran in our st-seq.

> Now type "Clock" and hey, object not found!
> Now type "Utilities/Clock" and there it is.

  Since the Utilities directory was not in the paths (because we reset them),
you had to draw a path to the tool with the whole command.

> Type "Path Utilities".  Now type just "Clock" again.  There it is!

  Since you've now directed the system paths to the Utilities directory, you
only need to type the name of the tool and it'll find it.  A little clearer?
That's why the Path command is in the st-seq; we set things up there so we
don't always have to type the long version when we want a tool.  And that can
BE a real "long version" when you're calling up tools that are within
directories within directories within directories, etc.

  The basic Amiga directories have "built-in" paths, so the Amiga can get
going at boot-up.  Two are the c and s directories.  If you have no startup-
sequence at all and type "Dir" in a CLI, it doesn't come back with "object
not found" as the path to the c directory is automatic for tools.

  With the s directory, the automatic path is for scriptfiles, like the
startup-sequence.  The first thing it does at boot-up is seek the s directory
for "startup-sequence", even though no paths have been drawn there.  So got
the point yet?  Our little file "g" is also a scriptfile, so to edit the
st-seq, we type "f g" as fast as our little fingers can go and bang, there it
is.  If you've got ol' AddBuffers cranked up, the second time you "f g" it's
REALLY there.

  We keep our scriptfiles in the s directory as the system automatically
searches the s directory for scriptfiles; it lays a path for them.  The
Path command, remember, is only for tools.  If you had the scriptfile "g"
in the devs directory, say, and typed "f g", nothing would happen.  Type
"Path devs", then "f g" and still nothing happens.  Path is only for
tools.  S is the directory you keep scriptfiles in unless you plan on
spelling out the whole path during the command.  In this case, "f devs/g"
would work fine, as you specified to the Execute command the directory the
file "g" was in.  That's "f", by the way, as in "Fire One!"  I DID say some-
thing about "Silent Service", didn't I? ;)

  That little file "g" is just the start, of course.  We can issue all kinds
of commands with just a flip of our fingers with scriptfiles kept in the s
directory and our copied Execute command "f".  We're not going to delete the
original command Execute, by the way, as, like leaving the t directory on
the disk even though it's empty, some future programmers might seek out
the command Execute by name, never believing in their wildest nightmares
that anyone would have the gall to slice up a Workbench like we're doing.

  The ONLY other command we "shorten" is EndCLI, just because it's hard to
type quickly.  You "Copy c/EndCLI c/e" and now "e" is your "EndCLI".  Got a
loose DOS window cluttering up the place?  Hit e, Return and bang, it's gone.

  Want to have a tiny (possibly your only) laugh on the 2.x/3.x gang?  Their
"EndCLI" is built-in to ROM, so they don't have an actual file in their c
directory to rename.  So, they either have to laboriously type it out every
time, or lower every shred of self-esteem they possess and BORROW one from an
old, clunky 1.3 disk.  <chuckle>

  To be open-minded..at least on this one tiny little point..I'm forced to
admit that's it's also common to rename the Delete command to "d", like we
did when we cleaned up the c directory.  It's just one of those things that
you have to weigh out and decide for yourself.  As you know, when you delete
something in DOS, it doesn't come back with any good-neighborly message
asking you if you're just downright sure you want to delete this puppy, it's
just gone.  It strikes me now, as I'm sure it struck me then, that the LAST
thing we all-thumbs Beginners need is a quicker Delete command!  In just
the time it takes to type out the word, you have enough time to mentally
check if you really want this file deleted.  And besides, you goof around
on this thing long enough and eventually you'll enter some command like
"Delte TestMe.file" and the computer will respond "unknown command" and
you'll look up and realize with semi-shock that the TestMe.file was the
LAST thing you wanted deleted!  Saved by the misspell!  It is, on the other
hand, rather difficult to misspell the word "d".

                                       *

  Here are some of my s scriptfiles:

         a   - Run Type df0:MyFiles/ArchiveList

         aa  - Run Ed df0:MyFiles/ArchiveList

         g   - Run Ed df0:s/startup-sequence

         gg  - Run Ed df1:s/startup-sequence

         for - FailAt 25
               Format drive df1: name Formatted noicons ;lazy Format command

         b   - Run df0:SID          ;runs Directory Utility

         l   - SetPrefs Inlace      ;switches to Interlace screen/colors
               Lace

         ll  - Lace                 ;switches to non-Interlace screen/colors
               SetPrefs Nolace

         p   - Fac -p 0 -p 1        ;purges FaccII's buffers, both drives

         dr  - Delete Ram:#? all    ;deletes everything in Ram

         m   - Delete Ram:#? all    ;deletes everything in Ram and quits
               Fac -q                FaccII to get back most of the memory

         mm  - deletes Ram, stops as many sub-routines (like FastFonts) as it
               can, gets back as much memory as possible.  We'll talk more
               about it later

         mback - puts back everything mm took out


  Now some, like mm, execute a list, or script of commands, and that's why
scriptfiles are needed.  Others, like "b", just fire up my Directory
Utility (if you don't know what a DU is, you've got a real surprise coming).
I could just rename the DU "b", then simply type "b" in the CLI window and
up it would pop, but frankly, that's a stupid name for a tool.  Not to
mention how quickly it could get out of hand, renaming commands, scriptfiles
AND tools with single letters.  We'll leave things just as they are: you get
two single-letter commands in c, EndCLI and Execute, but nothing else will be
single or dual letters on the Bench except scriptfiles kept in the s dir.
Abide by those rules and you'll save yourself lots of headaches in the
future.

                                       *

  The program Lace I included with the tutorial is the best Interlace
switcher I can find.  There are bunches of them around, half of them called
"Lace", so I thought since it's pretty small I'd toss it in.  It's not
perfect in that it doesn't remember where the windows were when you return to
Interlace mode, but hey, so someone sacrificed program quality in order to
keep the size down.  Gee, what a surprise.

                                       *

  If you don't have a modem (what have you been doing, reading??), you'll
have to hoof it down to whoever near you has PD/Fred Fish disks, decipher
your way through the Index and pick up which of the following (or substi-
tutes, if you dare) you can.  The disks are only a couple of bucks each, you
get a whole bunch of needless crap on each one, and best of all you get the
honor of personally throwing away the junk generic disks when you've taken
what you want off them.  I'm not being a snob here; if you ever loose
something valuable you had stored on a junk disk you'll never forgive
yourself.  Or me.

                                       *

  If you just happen to HAVE a modem...well THANK GOD!!  Can you believe
that other guy I was just talking to?  Doesn't even have a modem yet and
says he has, get this, a "computer"!  Har! Har! Har!  What that guy has is
the "preparation for a computer", as tremendously hip people like ourselves
know.

  When you first get on a BBS, you'll be asked for your name and password,
and when you don't have one, it'll assume you're a new user and will proceed
with the registration process.  Some boards will have you type in something
like NEW USER from the beginning.  The registration consists of name, maybe
address, phone number, type of computer, maybe a few vital details about your
computer.  If you don't have someone there beside you who's been on a BBS
before, don't worry about it.  You know you've got a Commodore Amiga, so
once you enter that code most everything else should work just fine.  If
it asks you for a "Protocol", pick ZModem, of course.  ALWAYS make sure your
protocol matches the BBS's.  Screen width is 80, page length is usually 22 or
so for non-interlace scree, 44 for Interlace.

  After you register, different things will happen, depending on the SysOp
(System Operator) of the BBS, how trusting he is, etc.  Some will want you to
call back a few days later after you've been "validated", some will let you
on right away.  If you're allowed immediate access to the message base and
files, some will let you write mail and download files immediately and some
will only let you look around.  Either way, when you have access to the files
you'll want to use the S)earch feature to dig up the downloads you want by
name.  You'll also want to browse through the various sections to see what's
cookin'.  Most boards have an upload/download ratio, something like 30 to 1,
just to make sure you're not a complete leech.  Some boards give you more
time (starting at, say, thirty minutes) the more you upload, some just give
you, say, an hour, period.

  Uploading is kinda fun.  Uploading some righteous new hack or animation to
one of your favorite boards gives you a good feeling.  The best way to dig
up the latest stuff is to look at the (N)ew files when you first get on, and
those are the ones most likely to be needed elsewhere.  I have uploaded
easily more than thirty megs myself.

  Just call me the ol' file shuffler.

                                       *

  Update Note:  Make that "100". :)

                                       *

  So slap a blank disk in df1 and download:

         comp. bytes   prog bytes

Conman      14,277      1,100  - CLI line editor, a must
DU-VI       50,220     35,456  - best basic DU I've found, also a must
FileType    20,589     25,988  - a good file identifier
GShow       17,408     15,712  - shows pics
IconLab     55,428     68,768  - excellent icon tool
Less1.1     17,384     22,364  - replaces Type, much better
LHA         89,946     54,020  - to compress and decompress files, a must
PrefCh      14,034      4,112  - change Prefs while booted-up, a must
Mackie      19,361      7,488  - pops up a CLI window at the press of 2 keys
Runback      4,877      3,268  - replaces Run in many cases, a must
Select       8,413      5,412  - select your st-seq at boot-up, a must
PlayBeep    44,068     10,344  - changes error beep and screen flash
WhereIs     29,539     12,328  - finds lost files
PKAZip      67,939     89,004  - to decompress .zip files, a must
Zoo         70,009     41,428  - to decompress .zoo files, a must


  I include the compressed bytes to compare with the file on the BBS, but
both it and the program bytes are subject to change.  People add things,
archiving formats differ, etc.  Also, the names are sketchy, at best, use
"keywords" when you use the Search feature, not the whole entire name.

  If I mention a version number, like "Less1.1", try and get that partic-
ular one.  It's not unusual for a "new, improved" version to not be as good
as the older one.  What do you mean, you're `not surprised'??

  Try to find the Directory Utility DU-VI.  Most of the DU's around are
single-screen and this one's a double.  You'll also notice the occasional
file with a .zoo or .zip ending, which is why you need the Zip and Zoo
programs.

  Another thing to note is that you can't tell in the slightest how many
bytes a program is by the compressed size.  There's a good example above.
The DU-VI archive is some 50,000 bytes compressed, which might lead one the
think that by the time it's decompressed it'd be HUGE..but it's not.  As you
can see, the actual program is only 35 kbytes, very modest for all it does.
The bulk of the compressed file is the "c source" included in the file.  And
some docs can be pretty hefty.  I've seen 100k docs for 15k programs.


  After you've got that gang, the next ones to get are:

                  comp. bytes

      Beep            2,967   - a small beep sound for help with scriptfiles
      DL             11,941   - better List command
      Edible         14,395   - removes binary from text
      Filter          3,555   - removes command garbage (^M's) from text
      IconType        4,648   - changes type (Tool, Project) of icon
      IFFencode       6,540   - "snapshots" screen, saves as pic
      JBLS           10,588   - another better List command
      Melt           13,193   - maybe the greatest screen hack of all
      NewFlush        1,582   - flushes libs, etc from memory
      NewFonts       52,001   - neat fonts for paint & processor
      NewSweep        2,540   - this or NewFlush will do
      NewZap3.1      31,744   - lets you edit binary things like tools
      SView           5,248   - slightly different type of pic viewer
      Zoomlens        6,344   - just a cute Bench tool


  You'll also want to get anything else that looks intriguing, it obviously
depends on where your interests are.  There are, for example, some great
nudes on the BBSs.  There are some decent games (my favorites at the
moment are SnakePit and Cycles), game editors, and lots of tips 'n tricks
for commercial games.

  If you're into audio you'll want to pick up some Play programs and start
unraveling the IFF/RAW/8XVS/DMCS/SMUS/SONIX enigma.

  There are some great graphic demos around, such as Colorful, Dazzle,
Multiscope and Nemesis.  There are some great animations, such as Froggy,
CPUS, BThrows and MarbleFac.  The two premiere ones I've seen are "Stamp
Collector" and "NotAgain", both by the esteemed Dr.  Gandalf.  If you're
going to get NotAgain, dig up "Boing" first, just for the historical
reference.  The Boing Ball is the semi-official Amiga trademark.  I bet I've
got forty pics, anims, hacks, demos, intros, you-name-it on my board with a
Boing Ball somewhere in it.

  There's also the occasional business program, with some BBSs catering
almost exclusively to the business end of the machine, like some boards are
devoted exclusively to programmers.

                                       *

  And now, guess what?!  It's time for some more of that neat CLI stuff!!
Oh please, Mr. BenchMaster, can we have Assign first??

  Sorry kids, like dessert, you'll have to finish your plates before we get
to the good stuff, and that means every last byte!  <slapping knee>

  Okay, I'm just going to skip through the c directory; most of the commands
just kind of do one thing so don't need much additional comment.


AddBuffers - keep it until you get FaccII

Assign - sorry, next section

Avail - tells you available memory

Break - Will stop some programs that otherwise don't have an off command, but
        don't count on it.  Procedure is to first type Status to see which
        # task it is, then "Break #".  Will also tell Wait when a program is
        through, like in the 1.3 StartupII file

CD - sorry, next section too

Copy - makes a copy of a file where you specify, with a different name if you
       so further specify.  Use "all" to copy the directory and all sub-
       directories and files within

Date - used to set date and time

Delete - deletes specified file unless "all" is used, then deletes specified
         directory AND all subdirectories/files within.  When you use "all",
         be SURE you want to.  The CLI is very unforgiving, compared to the
         Workbench, so if you're deleting-something-all, be SURE

Dir - shows contents of directory or device

Echo - for printing out text in a CLI window

Ed - the "text editor", "screen editor", or "system screen editor",
     depending on which book's open at the time.  A "screen editor" would
     alter the size of the Workbench screen, maybe make it a triangle, maybe
     add some little scrolly things at the corners, gosh, just all kinds of
     great possibilities..therefore I surmise by default (hey, the original
     meaning of the word) that this is a "text editor".  I'll talk more
     about it in a bit.

Else, If, EndIf - next section

EndCLI - closes CLI window; doesn't close if you've Run certain programs
         still in operation (that's what Runback is for)

Execute - a "Run" for scriptfiles, if I may be so bold

FailAt - makes a scriptfile keep on running if a command fails.  I'll
         talk more about it later.

FastFonts - speeds up text output and changes default font

Fault - translates error message number into semi-English

IconX - runs scriptfiles from icons

Info - shows current disk space available, which devices mounted

Install - to make a blank disk bootable

Join - combines textfiles together

List - lists blocks in dir or bytes of individual file if specified, also
       date and time file was last copied or saved.

LoadWB - loads up the Workbench screen

MakeDir - makes a new directory, but not the icon for it.  For the .info file
          you have to copy over (and rename) another drawer icon, or make up
          a new one in IconEd.  Drawer icons don't actually have to look like
          drawers, I remind you

NewCLI - it differs from the CLI command that was in the System drawer in
         only one way, but you can play with them.  Both can have their
         default window sizes changed with NewZap

Path - mentioned throughout the tutorial.  Paths started up in the st-seq
       are forever, paths started once you've booted up are only good for
       the task they're in, or subsequent tasks (NewCLI's) from that task

Quit - quits a scriptfile

Rename - renames files as well as moves them.  Learn this guy as well as Copy

Run - for tools/programs

SetClock - for setting the internal and system clocks

SetPatch - fixes minor bugs in ROM

Sort - alphabetizes textfiles

Stack - mainly needed for big graphics things, increases Ram "overflow"

Status - gives you status of current CLI tasks

Type - goes into the dumper as soon as you get Less (or rename it Type2)

Wait - holds up scriptfile for requested number of secs/mins

Why - like Fault, gives you feedback on error.  Use right after boo-boo


  Okay, that's it for those clowns.

  Assign, Avail, Info, List, Path and Status are the six commands you type
into the CLI to check the current condition of the system.  Write them down
on a small, separate piece of paper and tape it somewhere obvious.  These
are your direct link to the system, so use them, learn them, figure out what
every little scrap of data means, slap 'em in the CLI whenever you have the
slightest question as to what's going on.  You will eventually feel like you
are actually controlling the computer, rather than simply being bewildered
by it, and learning, knowing and using these six commands are the shortest
and best path to that goal.

  (To all the DiskMaster fans in the audience who just gasped at that last
statement, let me quickly add that you don't control the SYSTEM with a
Directory Utility, you only control FUNCTIONS.  DU's are really great, but
they're just tools, after all)

                                       *

  Well, I fibbed.  This is the next section and we're NOT going to go
over those other commands just yet.  Aw-w, gee Uncle BenchMaster, c'mon,
just one little Assign, pretty-please???

  Well, okay.  Geez, I'm such a sucker for you brats.  Now, remember when I
said we'd wipe out the fonts dir, get all the space back and still have
access to the fonts?  Here's how:  We made that fonts dir on the disk in df1,
so we'll Assign the fonts over to that disk so when Notepad or whatever goes
looking for "fonts", they'll find them.  Pop a copy of Notepad off the master
disk into the Utilities drawer or boot up a standard WB with Notepad on it.

  Slap ol' FontDisk in df1.  Think one whole big disk is too much to devote
to some punky little fonts?  Well, if you're not into them, that's true.  If
you are, however, you may eventually end up with 754,888 bytes (and counting)
worth of the little beggars, like Guess Who.

  To run Notepad with df1's fonts, somewhere before you start up Notepad
you need to assign the fonts dir over to the fonts dir on df1, and this you
can do a number of ways:

  -  You can just put "Assign fonts: df1:fonts" in your st-seq but then
FontDisk always has to be in df1 when you're booting up or it'll stop.

  -  A variation on the above would be to put an

                   If exists df1:fonts
                   Assign fonts: df1:fonts
                   EndIf

in the st-seq so it can see if df1:fonts is there or not.  One hitch
with this is that unless FontDisk is in df1 during boot-up you'll STILL
have to Assign them over before using the Notepad.  Also, you could have
some ol' game disk with a font dir on it in df1 by mistake and things would
really mIxT uP gEt.

  -  You could, of course, just type "Assign fonts: df1:fonts" in a CLI
before using the Notepad every time.  Personally, I can't even imagine it.

  -  You could write a scriptfile saying "Assign fonts: df1:fonts", call it,
say, "fo" (for fonts), and "f fo" before firing up the Notepad.  But then, of
course, you still have to remember to do it every time.

  -  And there's one more hitch.  Let's say, okay, you've now assigned the
fonts to df1.  Great, what happens when you try to fire up some other program
later and you've either taken FontDisk out of df1, or the fonts the game is
looking for aren't on FontDisk?  Leaving the fonts directory Assigned to a
directory on another device is looking for trouble.

  So obviously you'll have to do it the right way.  AND you have to be able
to run the whole thing from ONE icon.  AND it's due by Part5.

  Hey, you've heard of mid-terms?

  Consider this one.

                                      *

  Clue1: (in Official Seventh Grade Typewriter Code):  OvpmC

  Clue2:  tim mpy Tim

                                       *

  A few notes on paths:  Any paths you enter in the st-seq are there forever.
If you enter "Path reset" in a CLI, it only wipes out the paths in that CLI,
or any NewCLI's you run from it.  If you start up some new paths in a CLI,
those paths are only accessible through that CLI or any new CLI's from it,
whether you enter the NewCLI c command, or run the CLI tool.  Those new CLI
processes retain the paths set in the CLI they came from.

                                       *

  Hmm..  I said "a few notes", and then I actually just left a few notes!

  Must be losing my touch. ;)

                                       *

  Three items about the actual CLI window: You can usually halt the process
by inputing a character, like you stop the original Type program.  To start
it back up again you hit the backspace key.  You can usually stop it com-
pletely by hitting Ctrl-C or sometimes Ctrl-X.  If it's a scriptfile, like
the st-seq, you stop it by hitting Ctrl-D.  On a few rare occasions I've seen
Ctrl-\ stop a program, so who knows?  If you want to enter another command
while one's already running, hit Ctrl-J, enter the command, then Return.  The
CLI will finish up the first task then perform the second.  If I'm doing
something that takes a while, like compressing some large animation, I
enter "LHA a (newfilename) *", Return, the compressor starts doing its thing,
I hit Ctrl-J, enter "Beep", Return, and when the LHA process is done it plays
the little Beep program to let me know.

                                       *

  Perhaps a note on the good Doctor would be in order about now.  If you're
writing to or reading from a disk, things suddenly grind-grind-grind and up
pops a requester saying "Sorry kid, it's Read/Write Error time", the proper
procedure is this:

  If you're writing TO the disk out of Ram, first grab a fresh disk, slap it
in df1 and get the Ram file taken care of.  Pop up the DU if you haven't and
copy all the files to a fresh disk.  Feel lucky.  Reformat the disk, maybe
with something like BFormat, which tests it as it goes.

  If you were reading FROM the bad disk, this is where things get dicey.  The
first thing I'd do would be to try and read it from another drive.  Drives
definitely differ.  Next up, it's time to put on your Doctor hat and get to
it.  DiskDoctor works about as well as any of the PD stuff, but if you've got
FixDisk or Recover, I'd try those first.  If you had a commercial fix-it
program, like QuarterBack Tools, you'd certainly try that first.  But if all
you've got is the good Doctor, tell him to "DiskDoctor df1:" and see what ya
get.  Hopefully it was just one or two sectors that got zilched and you can
recover all or most of the files.  Hopefully.

  The good Doctor's main role is to restore freshly deleted files.  I say
"freshly" because if you've written to the disk since you deleted the file,
it might be history.  Otherwise, if you accidentally delete a file, just slap
the disk in df1 and let the good Doctor do his thing.

                                       *

  The Stack command is essential for certain programs to run correctly,
usually large animations.  If it has an icon with it there'll be a "16000"
or something in the STACK box in the Info window.  If you're running it from
a scriptfile, you'll have to have a "Stack 16000" before the program.  It's
always better to overestimate how much Stack you need if you're not sure, as
it'll usually be Mr. Guru knocking on the door if you don't.  If you're
into downloading graphic hacks, you'll want to remember ol' Stack, as some
definitely need it and the icon might be gone or whatever.  One indicator of
insufficient stack space is the good ol' CANCEL/DEBUG "requester", so reboot
and type in "Stack 16000" in the CLI if you're going that route, or enter
the 16000 in the STACK box in the Info window and try it again.

  You'll also need it if you want to Sort (alphabetize) great big columns of
words, like 40K-plus.  The original Sort command is really garbage, there's
a much better one floating around the BBSs called SuprSort.  But it'll still
Guru out on huge lists if you don't "Stack 100000" first.

  We saw above that if we entered new paths in a CLI, future CLI's from
that same CLI also knew the new paths.  The Stack command also works as an
example of how CLI tasks work.  If you enter "Stack", the computer responds
"current stack size is 4000 bytes".  Enter "Stack 16000", then "Stack" and
the computer will tell you the current stack size is now 16000.  Fire up a
NewCLI from that CLI, enter "Stack", and it'll respond "16000".  Fire up
a NewCLI from THAT CLI and the new one will also respond "16000".

  Enter "Stack 16000" in the startup-sequence, followed by a "NewCLI".  If
you "Stack" in that new CLI window after booting up, it responds "16000",
but every other CLI, NewCLI, DU's CLI, Mackie's CLI, etc, on the Bench will
be at the default 4000, no matter what's in the icon's Stack box, or where
you put the Stack command in the st-seq in relation to LoadWb.

  Let's see..was it LoadWb..or Path?   Hmmm....maybe that didn't have
anything to do with it.  Gosh...I've kinda forgotten now.

  All I remember is that there's a real easy way to simply click on the CLI
icon and automatically have the Stack set to 16000.

  I guess you'll have to help me out.


  Also due by Part5.

                                       *